I also want to note, I think the whole api here (both the old and new, my goal here wasn't to change it much yet) is super weird. It kind of puts the burden of the dependency on both the framework and the app, while providing no real benefit.

However now that it's just a reducer directly now, I think maybe there's a way we can hide this completely from the app (as it's just another reducer to combine). Really all we should really expose to the app is some kind of configuration interface imo.

However now that it's just a reducer directly now, I think maybe there's a way we can hide this completely from the app (as it's just another reducer to combine). Really all we should really expose to the app is some kind of configuration interface imo.

This is an interesting idea. What would this configuration look like?

Is this a breaking change for misk apps?

Yes it is because of my comment above, this is basically how it would look in an example app.
https://github.com/cashapp/misk-web/pull/1947/files#diff-6f5a489992d29756a72f1270e0764752d228278c170f85513dec2a7717ea757aR65-R70

So I'm thinking of bundling this + the rest of the big upgrades (react, redux) in a v0.6 release.

This is an interesting idea. What would this configuration look like?

The router itself doesn't really have many configuration options: https://github.com/salvoravida/redux-first-history#options, so I don't think there's much to configure there. I'm thinking more of reversing the flow in a sense. So for example, rather than us calling to the app with the routerReducer and having them mix it into their apps reducers, we receive the apps reducers and mix in the routerReducer there.